Method of generating media file and storage medium storing media file generation program

ABSTRACT

A method of generating a media file using a media file format in which a set of pictures including one or more pictures is coded and stored such that each picture is divided, in coding order, into two or more slices, and coded data of each slice is stored as NAL unit data, the method comprising: dividing each slice into two or more rectangular-shaped tiles and coding the two or more rectangular-shaped tiles; and providing a slice index box in the media file format such that a value indicating an ordinal position of each slice to which each tile belongs in each picture is described in the slice index box.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation, and claims the benefit, of U.S.patent application Ser. No. 14/412,193 filed Dec. 30, 2014, which is aNational Stage Application of International Application No.PCT/JP2013/004049 filed Jun. 28, 2013, which claims the benefit ofJapanese Patent Application No. 2012-148511 filed Jul. 2, 2012. Each ofU.S. patent application Ser. No. 14/412,193, International ApplicationNo. PCT/JP2013/004049, and Japanese Patent Application No. 2012-148511is hereby incorporated by reference herein in its entirety.

TECHNICAL FIELD

The present invention relates to a method of generating a media file anda storage medium storing a media file generation program, and moreparticularly, to a technique of formatting a media file such that eachpicture is divided into rectangular-shaped tiles and coded.

BACKGROUND ART

A great advance has been made in digital technology. As a result, it hasbecome very popular to take a high-resolution motion picture using adigital camera or a digital video camera. To store a digital motionpicture in an efficient manner in a storage medium typified by a flashmemory, the data is generally compressed (coded). H.264/MPEG-4 AVC(hereinafter referred to as H.264) is a technique widely used to codemotion pictures.

A Joint Collaborative Team on Video Coding (JCT-VC) has been establishedby the ISO/IEC and the ITU-T to develop a further high efficiency codingstandard as a successor to the H.264 coding standard. More specifically,a High Efficiency Video Coding (hereinafter referred to as HEVC)standard is under development in the JCT-VC.

In the standardization of HEVC, various coding tools are underdiscussion, in terms of not only an improvement in coding efficiency butalso other factors including implementability, processing time, and thelike. Issues under discussion include parallel processing ofcoding/decoding, a technique of dividing a picture into slices along ahorizontal direction to increase error resilience, a technique ofdividing a picture into rectangular areas called tiles, and othertechniques (NPL 1). Use of slices or tiles makes it possible to performcoding and decoding in parallel, which allows an increase in processingspeed. Use of slices or tiles also allows a reduction in memory capacitynecessary in the coding/decoding process. HEVC allows it use a mixtureof dividing into slices and dividing into tiles.

A technique called a motion constrained tile sets (MCTS) technique isused to code a video sequence using the division into tiles such that itis allowed to decode only a particular tile independently of the othertiles from a coded stream of successive pictures (NPL 4). When a codedstream includes an MCTS SEI message, a video sequence is supposed to becoded so as to satisfy the following conditions.

All pictures in the video sequence are coded such that the division intotiles is performed in the same manner.

In MCTS coding, coding is performed without using a motion vector thatrefers to a pixel outside the tile set.

In decoding of a coded stream, when the coded stream includes an MCTSSEI message, it is allowed to extract only a tile set specified as MCTSfrom a sequence of pictures and quickly decode or play back theextracted MCTS tile set as a partial motion picture. Use of MCTS make itpossible to quickly decode only a region a user is interested in.Hereinafter, such a region of interest will also be referred as a ROI.

An AVC (Advanced Video Coding) file format (NPL 2) is widely used as amedia file format to store H.264 video data. It is expected that HEVCwill provide a media file format similar to the AVC file format.

When a low-resolution device is used to play back a movie including asequence of one or more high-resolution pictures each including, forexample, 4096 pixels in a horizontal direction and 2048 pixels in avertical direction (hereinafter referred to as 4096×2048 pixels), it maybe advantageous to extract a particular area and play back only theextracted area. This may apply, for example, to a use case in which aface of a particular person is extracted from a scene including manypeople and the extracted face is displayed in an enlarged manner. Insuch a use case, if a whole picture area of a picture in a movie isfirst decoded and a partial area is extracted and displayed, a longdecoding time (a delay time before the picture is displayed) and largepower consumption are necessary. Thus, when a partial area is extractedand the extracted area is played back, the capability of dividing eachpicture into tiles and coding the resultant tiles, and, in a playbackoperation, decoding only particular tiles provides advantages inparticular in terms of a reduction in delay time before the picture isdisplayed and a reduction in power consumption.

In the AVC file format described in NPL 2, coded data of each picture(denoted as sample data in NPL 2) is stored in units of coded data ofslices. The coded data of each slice is added with one-byte data calleda NAL header thereby being converted into NAL unit data. NAL stands forNetwork Abstraction Layer, and a detailed description thereof may befound, for example, in Section 7.4.1 of NPL 1, and thus a furtherdescription thereof here is omitted. In front of each NAL unit data,data indicating a NAL unit data length is put to indicate the datalength, in bytes, of the NAL unit data. Thus, in a process of playingback the media file written in the AVC file format, it is allowed toaccess coded data of an arbitrary slice in a picture without coding theslice.

In a case where coding is performed according to HEVC using a mode inwhich one slice is divided into a plurality of tiles, coding parametersnecessary in decoding each tile are described in a slice header to whichthe tile belongs. Therefore, even in a case where only part of tiles ina slice are decoded, it is necessary to decode the slice header of thisslice.

In HEVC, it is possible to calculate the number of pixels in thehorizontal direction and that in the vertical direction of a tile fromcoding parameters in a picture parameter set (PPS) described in Section7.4.2.3 of NPL 1. More specifically, for example, it is possible tocalculate the numbers of pixels in the horizontal and verticaldirections for each tile from a parameter (num_tile_columns_minus1)indicating the number of tile columns minus 1, a parameter(num_tile_rows_minus1) indicating the number of tile rows minus 1, andthe numbers of horizontal and vertical pixels in a sequence parameterset (SPS) described in NPL 1.

However, the numbers of pixels in the horizontal and vertical directionsof each slice are not described in SPS or PPS, and thus acquisition ofthe numbers of pixels in the horizontal and vertical directions of eachslice is possible only by decoding the slice of interest.

That is, when a particular tile in a picture is extracted and decoded,it is not possible to know the ordinal position of a slice in which thetile of interest to be decoded is included without decoding slices.Therefore, it is necessary to decode the whole picture area, whichresults in a long decoding time and large power consumption.

HEVC also allows a coding mode in which each picture is divided intotiles and slices such that a plurality of slices are included in onetile. However, as in the previous case, no way is provided to know whichslice is to be decoded to get a correct tile to be decoded, withoutdecoding slices. Therefore, it is necessary to code the whole picturearea, which results in a long decoding time and large power consumption.

In view of the above, the present invention provides a technique ofextracting a particular tile in a picture and decoding the extractedtile at an improved processing speed, with reduced power consumption,and with a reduced memory capacity.

CITATION LIST Non Patent Literature

[NPL 1]

JCT-VC document, JCTVC-I1003_d4.doc available at Internet site,http://phenix.int-evry.fr/jct/doc_end_user/documents/9_Geneva/wg11/

[NPL 2]

ISO/IEC 14496-15 Advanced Video Coding (AVC) file format

[NPL 3]

ISO/IEC 14496-12 ISO base media file format

[NPL 4]

JCT-VC document, JCTVC-M0235-v3.doc available at Internet site,http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/

SUMMARY OF INVENTION

In an embodiment, the invention provides a method of generating a mediafile using a media file format in which a set of pictures including oneor more pictures is coded and stored such that each picture is divided,in coding order, into two or more slices, and coded data of each sliceis stored as NAL unit data, the method including dividing each sliceinto two or more rectangular-shaped tiles and coding the two or morerectangular-shaped tiles, and providing a slice index box in the mediafile format such that a value indicating an ordinal position of eachslice to which each tile belongs in each picture is described in theslice index box.

In an embodiment, the invention provides a method of generating a mediafile using a media file format in which a set of pictures including oneor more pictures is coded and stored such that each picture is divided,in coding order, into two or more slices, and coded data of each sliceis stored as NAL unit data, the method including dividing each sliceinto two or more rectangular-shaped tiles and coding the two or morerectangular-shaped tiles, and providing a tile index box in the mediafile format such that a value indicating an ordinal position of a tileat the beginning of each slice in each picture is described in the tileindex box.

In an embodiment, the invention provides a method of generating a mediafile using a media file format in which a set of pictures including oneor more pictures is coded and stored such that each picture is divided,in coding order, into two or more slices, and coded data of each sliceis stored as NAL unit data, the method including dividing each sliceinto two or more rectangular-shaped tiles and coding the two or morerectangular-shaped tiles, and providing a tile offset box in the mediafile format such that the number of bytes indicating an offset from thebeginning of coded data of each picture to coded data of each tile isdescribed in the tile offset box.

The media file format according to one of embodiments of the inventionallows it to access coded data of any tile without decoding coded dataof a slice that does not include any tile to be decoded. Thus, when onlyparticular tiles are decoded and displayed or played back, a reductionin decoding time and reduction in power consumption are achieved.Furthermore, a memory capacity necessary is smaller than is necessary todecode the whole picture area.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a diagram illustrating a media file format according to anembodiment.

FIG. 2 is a diagram illustrating an example of a manner of dividing apicture into slices and tiles according to an embodiment.

FIG. 3A is a diagram illustrating a format of a slice index boxaccording to an embodiment.

FIG. 3B is a diagram illustrating an example of a content of a sliceindex box according to an embodiment.

FIG. 4 is a flow chart of a process of coding a slice according to anembodiment.

FIG. 5 is a flow chart of a process of generating a media file accordingto an embodiment.

FIG. 6 is a diagram illustrating a use case in which only particulartiles are extracted from a media file and played back according to anembodiment.

FIG. 7 is a diagram illustrating a flow chart of a process of extractingonly particular tiles from a media file and playing back them accordingto an embodiment.

FIG. 8 is a diagram illustrating a media file format according to anembodiment.

FIG. 9A is a diagram illustrating an example of a format of a tile indexbox according to an embodiment.

FIG. 9B is a diagram illustrating an example of a content of a tileindex box according to an embodiment.

FIG. 10 is a diagram illustrating an example of a media file formataccording to an embodiment.

FIG. 11A is a diagram illustrating an example of a format of a tileoffset box according to an embodiment.

FIG. 11B is a diagram illustrating an example of a content of a tileoffset box according to an embodiment.

FIG. 12 is a diagram illustrating an example of a media file formataccording to an embodiment.

FIG. 13 is a diagram illustrating an example of a manner of dividing apicture into slices and tiles according to an embodiment.

FIG. 14A is a diagram illustrating an example of a format of anumber-of-slices-in-tile box according to an embodiment.

FIG. 14B is a diagram illustrating an example of a content of anumber-of-slices-in-tile box according to an embodiment.

FIG. 15 is a flowchart of a process of coding a slice according to anembodiment.

FIG. 16 is a flow chart of a process of generating a media fileaccording to an embodiment.

FIG. 17 is a diagram illustrating a flow chart of a process ofextracting only particular tiles from a media file and playing back themaccording to an embodiment.

FIG. 18 is a diagram illustrating an example of a media file formataccording to an embodiment.

FIG. 19A is a diagram illustrating an example of a format of a tileoffset box according to an embodiment.

FIG. 19B is a diagram illustrating an example of a content of a tileoffset box according to an embodiment.

FIG. 20 is a diagram illustrating an example of a hardware configurationof a computer usable to practice a media file generation methodaccording to embodiment.

FIG. 21 is a diagram illustrating a tile set coded as MCTS according toan embodiment.

FIG. 22 is a diagram illustrating a media file format according to anembodiment.

FIG. 23A is a diagram illustrating a format of an MCTS slice index boxaccording to an embodiment.

FIG. 23B is a diagram illustrating an example of a content of an MCTSslice index box according to an embodiment.

FIG. 24 is a flow chart illustrating a process of extracting only aparticular tile from a media file and playing back the extracted tileaccording to an embodiment.

FIG. 25 is a diagram illustrating an example of a content of an MCTSslice index box according to an embodiment.

FIG. 26 is a diagram illustrating a media file format according to anembodiment.

FIG. 27A is a diagram illustrating a format of a ROI tile set boxaccording to an embodiment.

FIG. 27B is a diagram illustrating an example of a content of a ROI tileset box according to an embodiment.

FIG. 28 is a diagram illustrating a media file format according to anembodiment.

FIG. 29A is a diagram illustrating a format of a ROI tile index boxaccording to an embodiment.

FIG. 29B is a diagram illustrating an example of a content of a ROI tileindex box according to an embodiment.

FIG. 30 is a diagram illustrating valid samples in each tile setaccording to an embodiment.

FIG. 31 is a diagram illustrating a media file format according to anembodiment.

FIG. 32A is a diagram illustrating a format of a ROI valid sample boxaccording to an embodiment.

FIG. 32B is a diagram illustrating an example of a content of a ROIvalid sample box according to an embodiment.

FIG. 32C is a diagram illustrating an example of a content of a ROIvalid sample box according to an embodiment.

DESCRIPTION OF EMBODIMENTS

The invention is described in further detail below with reference toembodiments in conjunction with accompanying drawings. Note thatembodiments are described below only by way of example but notlimitation.

First Embodiment

FIG. 1 illustrates a format of a media file in which coded data isstored according to a first embodiment. The format according to thepresent embodiment may be applied to a case where a picture is dividedinto slices and tiles such that a plurality of rectangular-shaped tilesare included in one slice.

As illustrated in FIG. 1, in the media file format according to thepresent embodiment, as with the AVC file format, the format includes afile type box 100, a movie box 101, and a media data box 110. The box isa data type in which data is stored together with an identifierindicating a type of data and a data size. For further information aboutthe box, see Section 6.2 of NPL 3.

The file type box (denoted as ftyp in FIG. 1) 100 describes informationindicating a format employed by a media file. In a case where the mediafile is according to a HEVC coding format, hvc1, hev1, hvcC, or asimilar character string is described as an identifier in the file typebox 100.

The media data box 110 is a box in which a main part of media data suchas coded picture data or coded audio data is stored. As described inSection 5.3.4.2 of NPL 2, a set of coded data of pictures is stored inthe media data box 110 such that the set of coded data is divided intounits of sample data 111 each corresponding to one picture. Each sampledata 111 includes a plurality of pieces of NAL unit data each including,as described above, coded data of one slice and data indicating the datalength of the NAL unit.

The movie box (in FIG. 1, denoted as moov) 101 is a box storinginformation for use in decoding or displaying the data stored in themedia data box 110. The movie box 101 may include a sample table box (inFIG. 1, denoted as stbl) 102. In general, there are a plurality of boxesin a hierarchical manner between the movie box 101 and the sample tablebox 102. However, a further description of these boxes existing betweenthe movie box 101 and the sample table box 102 is omitted, because theydo not have direct relevance to the present embodiment. For informationabout these boxes, see Section 6.2.3 of NPL 3.

The sample table box 102 includes a sample size box 103, a HEVCconfiguration box 104, and a slice index box 105. In general, the sampletable box 102 includes further many boxes having no direct relation tothe present embodiment, and thus they are not illustrated in FIG. 1, andno further description thereof is given here. The sample size box (inFIG. 1, denoted as stsz) 103 describes the data length of each of allpieces of sample data 111 of the movie stored in the media data box 110.The HEVC configuration box (in FIG. 1, denoted as hvcC) 104 includesheader information corresponding to SPS and PPS for use in decoding eachpiece of sample data 111 in the media data box 110. The slice index box(denoted as sidx in FIG. 1) 105 will be described later.

Use of the file format described above makes it possible to performhigh-speed access to each piece of sample data 111 using sample size box103 or the like, and thus it becomes possible to easily realize aspecial playback mode such as a fast forward playback mode, a reverseplayback mode, or the like.

Note that the order of putting the file type box 100, the movie box 101,and the media data box 110 is not limited to that illustrated in FIG. 1.For example, those boxes may be stored in the media file in the orderthe file type box 100, the media data box 110, and the movie box 101.

FIG. 2 illustrates an example of a manner of dividing a picture of amovie into slices and tiles according to the present embodiment. Asillustrated in FIG. 2, each picture including 4096×2048 pixels isdivided into four slices each including 4096×512 pixels. In coding, whencoding is complete for all pixels in each slice, an end-of-slice flag iscoded to 1 to indicate that the end of the slice is reached. Thisend-of-slice flag corresponds to end_of_slice_flag in HEVC described inSection 7.4.4 of NPL 1.

In decoding, if a decoded end-of-slice flag equal to 1 is detected, thenthis means that a slice boundary is detected in decoding in a mediaplayback process.

In FIG. 2, each slice is internally divided into four tiles eachincluding 1024×512 pixels. In HEVC, each tile size may be set in thecoding process as illustrated in FIG. 2 by setting coding parameters inPPS, for example, as described below. Note that in the followingdescription, it is assumed by way of example that coding in HEVC isperformed in units called coding tree blocks each including 64×64pixels.

A parameter tiles_or_entropy_coding_sync_idc is a coding parameter usedto indicate whether a picture is divided into tiles and whether aplurality of coding tree block rows are to be processed in parallel.When this parameter is set to 1, that is,tiles_or_entropy_coding_sync_idc=1, this means that the picture isdivided into tiles.

A parameter num_tile_columns_minus1 is a coding parameter used toindicate a manner of dividing a picture into columns of tiles. Morespecifically, num_tile_columns_minus1 is set to be equal to the numberof tile columns of the picture minus 1. For example, when this parameteris set to 3 (num_tile_columns_minus1=3), then this means that thepicture is divided into 4 tile columns.

A parameter num_tile_rows_minus1 is a coding parameter used to indicatea manner of dividing a picture into rows of tiles. More specifically,num_tile_rows_minus1 is set to be equal to the number of tile rows ofthe picture minus 1. For example, when this parameter is set to 3(num_tile_rows_minus1=3), then this means that the picture is dividedinto 4 tile rows.

A parameter uniform_spacing_idc is a coding parameter used to indicatewhether the numbers of pixels in horizontal and vertical directions ineach tile in the picture are given explicitly. When this codingparameter is set to 0, then this means that the picture is equallydivided into tiles depending on the horizontal and vertical numbers ofdivisions specified by num_tile_columns_minus1 and num_tile_rows_minus1.On the other hand, when this coding parameter is set to 1, the number ofpixels in the horizontal direction in each tile is specified bycolumn_width[i] and the number of pixels in the vertical direction ineach tile is specified by row height[i]. Note that even when this codingparameter is set to 1, the picture may be equally divided into tiles.

A parameter column_width[i] is a coding parameter used to indicate thenumber of pixels in the horizontal direction in each tile based on thenumber of pixels in the horizontal direction in each coding tree block.For example, the parameter may be set as column_width[i]=16 (i=0, 1, 2,3).

A parameter row_height[i] is a coding parameter used to indicate thenumber of pixels in the vertical direction in each tile based on thenumber of pixels in the vertical direction in each coding tree block.For example, the parameter may be set as row_height[i]=8 (i=0, 1, 2, 3).

Further parameters are available. For example, if a parameter is setsuch as uniform_spacing_idc=1, then this specifies that the tiledivision in FIG. 2 is performed such that the picture is equally dividedinto tiles. In the decoding, it is possible to know the size of eachtile by analyzing the coding parameters included in PPS.

In the present embodiment, the slice index box 105 illustrated in FIG. 1is used to indicate the correspondence between tiles and slices, andmore particularly, indicate an ordinal number expressing the position ofcoded data of a slice (NAL unit data) to which coded data of a tile ofinterest belongs.

FIG. 3A illustrates an internal format of the slice index box 105. In abox size put at the beginning of the slice index box 105, 4-byte data isstored to indicate the total data length of the slice index box 105. Inthe present embodiment, the total data length of the slice index box 105is given by 4 bytes+4 bytes+2 bytes+the number of entries×2 bytes.

Following the box size, a 4-byte identifier is inserted to indicate abox type. In the present embodiment, a character string “sidx” (SliceIndex) is used as the identifier indicating the slice index box 105.

Following the box type, 2-byte data is inserted to indicate the numberof entries, that is, the number of data bodies. In the slice index box105 according to the present embodiment, the number of entries is equalto the number of tiles in a picture minus 1. Following the number ofentries, as many 2-byte slice indexes of respective tiles which are mainparts of data of the slice index box 105 are put as there are entries.

The slice index an ordinal number expressing the position of a slice towhich a tile of interest in a picture belongs. Use of the slice indexmakes it possible to quickly access coded data of a particular tile. Theslice indexes are stored in the same order as the order in which tilesare coded (upper left->upper right->lower left->lower right).

It is self-evident that a tile (tile #1) at a first position in thecoding order is included in a slice (slice #1) at a first position inthe coding order in the picture, and thus no slice index is inserted.For second and following tiles, if a tile of interest is included in aslice #2, a slice index thereof is set to 1. If a tile of interest isincluded in a slice #3, a slice index thereof is set to 2. When thenumber of slices included in the picture is N, the slice index takes oneof value in a range from 0 to (N−1).

FIG. 3B illustrates an example of a content of a slice index box 105 ina case where a picture is divided into tiles and tiles as illustrated inFIG. 2. In the example illustrated in FIG. 2, the number of tiles is 16,the number of entries is 15 and the data size is given by 4+4+2+2×15=40bytes.

Following the number of entries, slice indexes of the tile #2 to thetile #16 are inserted. As illustrated in FIG. 2, the tiles #2 to #4 areincluded in the slice #1, and thus 0 is stored as slice indexes of thetiles #2 to #4. On the other hand, the tiles #13 to #16 are included inthe slice #4, and thus 3 is stored as corresponding slice indexes.

Basically, the slice index box 105 is stored in the sample table box102. Note that the slice index box 105 may be stored in another box. Forexample, the slice index box 105 may be stored in any box in the moviebox 101.

Referring to flow charts illustrated in FIG. 4 and FIG. 5, a descriptionis given below as to a process of generating a media file in the formillustrated in FIG. 1 according to the present embodiment for a case inwhich coding is performed such that a picture is divided into aplurality of slices each including a plurality of tiles as in theexample illustrated in FIG. 2.

FIG. 4 is a flow chart illustrating a process of coding each slice in apicture. In step S401, coding parameters used in coding the slices areexternally set (by a user). Note that parameters associated with theslice dividing and the tile dividing are given in step S502 describedbelow with reference to FIG. 5, and the coding parameters given in thisstep S401 are not relevant to the slice dividing and the tile dividing.

In step S402, a coding process is performed on the coding tree block inthe slice. In HEVC, the coding tree block is a pixel block whose size isvariable within a range of 16×16 pixels to 64×64 pixels. The order ofcoding the coding tree blocks depends on how the picture is divided intoslices and tiles, although a further description thereof is omitted.Further information thereof may be found, for example, in Section 6.5.1of NPL 1.

In the present embodiment, coding of the coding tree blocks does notdepend on a particular coding algorithm, but any known coding algorithmmay be used, and thus a description thereof is omitted. In step S403,when coding is completed for each coding tree block, a determination isperformed as to whether coding is complete for one tile. If the codingis complete for one tile, the processing flow proceeds to step S404, butotherwise the processing flow proceeds to step S407.

In step S404, in response to the completion of the coding of one tile, aslice index is generated, which is to be stored in a slice index box 105which is to be created. In the present embodiment, the slice index iscalculated based on the information indicating the ordinal numberexpressing the position of the slice to which the coded tile belongs to.In this step S404, also a calculation is performed to determine thecoded data length in bytes of the coded data obtained as a result of thecoding of the tile.

In step S405, a determination is performed as to whether coding iscomplete for one slice. When the coding is complete for one slice, theprocessing flow proceeds to step S406, but otherwise the processing flowproceeds to step S407. In step S406, the end-of-slice flag is coded to 1to indicate that the coding is complete for the one slice, and theprocessing flow proceeds to step S408. In the case where the processingflow proceeds to step S407, in response to the determination that thecoding is not complete for the slice, the end-of-slice flag is coded to0, and then the processing flow returns to step S402 to code a followingcoding tree block.

In step S408, a coding parameter entry_point_offset, which is includedin a slice header in HEVC, is calculated from the coded data lengths ofthe tiles calculated in step S404. As described in NPL 1, firstentry_point_offset indicates an offset from the end of a slice header tothe beginning of coded data of a second tile. Similarly, secondentry_point_offset indicates an offset from the beginning of the codeddata of the second tile to the beginning of the coded data of the thirdtile. In this way, it is possible to access coded data of any tile basedon the entry_point_offset. In step S408, a slice header is generated andcoded from the entry_point_offset and the coding parameters set in stepS401 and used in the coding of the slice, and thus the generation ofcoded data of one slice is completed.

FIG. 5 is a flow chart illustrating a process of generating a media fileaccording to the present embodiment.

In step S501, basic parameters in terms of an image size, a colordifference format, and the like are externally set (by a user), and SPS,that is, a corresponding coding parameter set is generated. A NAL headeris added to the generated SPS and thus NAL unit data is generated.

In step S502, parameters are externally set (by a user) to specify howto divide each picture into slices and tiles, and put together withquantization parameters and the like in a corresponding coding parameterset PPS. A NAL header is added to the generated PPS and thus NAL unitdata is generated. In a case where the condition as to the slicedivision and the tile division for second and following pictures, as thecondition for the first picture, the setting in the step for the secondand following pictures is skipped.

In step S503, each slice is coded according to the flow chartillustrated in FIG. 4. In step S504, a NAL header is added to the codedslice data generated in step S503 thereby generating NAL unit data. Thecoded data length (in bytes) of the NAL unit data is then calculated bydetermining the sum of the data lengths of the respective pieces ofcoded tile data calculated in step S404 of FIG. 4, the data length ofthe slice header, and the data length (1 byte) of the NAL header.

In step S505, a determination is performed as to whether coding iscomplete for one picture. If the coding is compete for one picture, theprocessing flow proceeds to step S506, but otherwise the processing flowreturns to step S503 to code a following slice. Instep S506, the NALunit data including the coded slice data and the data length thereof aremultiplex for one picture into one piece of sample data 111. In stepS507, the slice indexes generated in step S404 of FIG. 4 are collectedtogether into the slice index box 105 illustrated in FIG. 3.

In a case where all pictures in one movie sequence are divided intoslices and tiles in the same manner as illustrated in FIG. 2, only oneslice index box 105 exists in one sequence, and thus step S507 isskipped for second and following pictures. At some picture in the middleof one sequence, the slice dividing mode and the tile dividing mode maybe changed from those illustrated in FIG. 2. In this case, in step S507,at a picture at which the slice dividing mode and the tile dividing modeare changed, an additional slice index box 105 may be inserted, or oneor more entries may be added to the existing slice index box 105.

In step S508, a determination is performed as to whether coding iscomplete for all pictures specified to be coded. In a case where thecoding is complete for all pictures, the processing flow proceeds tostep S509, but otherwise the processing flow returns to step S502 tocode a following picture.

In step S509, NAL unit data of the coding parameter sets SPS and PPSgenerated in step S501 and step S502 is stored in a HEVC configurationbox 104. The storing of SPS and PPS into the HEVC configuration box 104may be performed in the same manner as the manner of storing SPS and PPSinto an AVC configuration box described in Section 5.2.4.1 of NPL 2, andthus a further description thereof is omitted.

In step S510, a sample size box 103 is generated based on the datalength of the sample data 111 generated in step S506. A sample table box102 is then generated by multiplexing the generated sample size box 103,the slice index box 105 generated in step S507, and the HEVCconfiguration box 104 generated in step S509. In step S511, the filetype box 100, the movie box 101 including the sample table box 102, andthe media data box 110 including the sample data 111 are multiplexedinto a media file, and thus the generation of the media file iscomplete.

FIG. 6 illustrates a use case of playing back a media file according tothe present embodiment. In the use case illustrated in FIG. 6, onlytiles #10, #11, #14, and #15 are extracted from the coded data codedusing the slice division and the tile division illustrated in FIG. 2,and the extracted tiles are displayed and played back. Referring to aflow chart illustrated in FIG. 7, a process of playing back part of amedia file by extracting only particular tiles as illustrated in FIG. 6from the media file generated based on the media file format accordingto the present embodiment.

In step S701, the HEVC configuration box 104 stored in the sample tablebox 102 in the read media file is analyzed to extract SPS and PPS.

In step S702, tile-to-be-decoded information indicating tiles to bedecoded (to be displayed) is set externally (by a user). The tiles to bedecoded may be specified arbitrarily by a user, for example, based onthumbnails or the like of the movie.

In step S703, the slice index box 105 stored in the sample table box 102is analyzed. That is, slices to be decoded are determined based on theslice index in the slice index box 105 and the tile-to-be-decodedinformation set in step S702. For example, in a case where thetile-to-be-decoded information indicates that tiles #10, #11, #14, and#15 are to be decoded as illustrated in FIG. 6, the slices to be decodedare determined as the slice #3 and the slice #4 from the slice indexillustrated in FIG. 3B.

In step S704, NAL unit data including slices determined, in step S703,to be decoded is read from the sample data 111 including the coded dataof the pictures to be decoded. In a case where playback is performed ina normal mode from the beginning of a movie sequence, the analysis onthe sample size box 103 is not necessary. However, to play back themovie sequence from somewhere in the middle thereof, the sample size box103 is analyzed and sample data 111 of pictures to be decoded is read.

It is possible to quickly access slices to be decoded based on the NALunit data length described in front of each NAL unit data in the sampledata 111. For example, to access NAL unit data including the slice #3,the slice #1 is skipped according to the coded data length described infront of the NAL unit data of the slice #1. If the NAL unit data of theslice #2 is skipped in a similar manner, the beginning of the NAL unitdata including the coded data of the slice #3 is quickly reached.

In step S705, the slice header of the slice including tiles to bedecoded is analyzed and coding parameters to be used in the decoding ofthe tiles are decoded. The slice header includes slice_segment_addresdescribed in NPL 1 to indicate a location of each slice in a picture. Bychecking the location of each slice in the picture and the informationon the division into tiles described in PPS analyzed in step S701, it ispossible to calculate the relationship between the coded slice data andthe tiles to determine which tile in the slice is to be decoded. Forexample, in FIG. 2, it is possible to indicate, by calculation, that thestart position of the slice #3 corresponds to the tile #9. In theexample illustrated in FIG. 6, it is possible to indicate, bycalculation, that the second tile (tile #10) in the slice #3 is a tileto be decoded. Furthermore, entry_point_offset is decoded from the sliceheader to acquire the offset indicating the offset of each coded data ofthe tile to access.

In step S706, based on entry point offset decoded in step S705, thecoded data of the tile specified in the tile-to-be-decoded informationis read and decoded. The decoding in the tile may be performed in asimilar manner to a general manner of decoding coding tree block, andthus a further description thereof is omitted.

In step S707, a determination is performed as to whether the decoding iscomplete for all tiles, specified to be decoded, in the slice. Morespecifically, in the example illustrated in FIG. 6, it is specified todecode two tiles from each of the slices #3 and #4. In a case where thedecoding is complete for all tiles to be decoded, the processing flowproceeds to step S708, but otherwise the processing flow returns to stepS706 to decode a following tile.

In step S708, a determination is performed as to whether the process iscomplete f or all slices including tiles to be decoded. For example, inthe case illustrated in FIG. 6, it is necessary to process two slices,that is, the slice #3 and the slice #4. In a case where the process iscomplete for all slices including tiles to be decoded (when the processis complete up to the slice #4 in the case illustrated in FIG. 6), theprocessing flow proceeds to step S709, but otherwise, the processingflow returns to step S704 to decode a following slice.

In step S709, all tiles decoded in step S706 are output. In step S710, adetermination is performed as to whether the decoding is complete forall pictures to be played back in the media file. In a case where theprocess is complete for all pictures to be played back, the decodingprocess is ended, but there are more pictures to be played back, theprocessing flow returns to step S701 to analyze and decode PPS of afollowing picture. Note that in a case where there is no change in thetile-to-be-decoded information and the slice dividing mode and the tiledividing mode in the process for the following picture, step S702 andstep S703 are skipped. There is no change in terms of the slice dividingmode and the tile dividing mode when there is only one slice index boxand all slice indexes in the slice index box are used in the process onthe first picture. Step S701 includes a process associated with PPS, andthus analysis may be perform on each picture.

Note that the flow chart illustrated in FIG. 7 is of a normal playbackmode. By properly changing the manner of controlling steps in units ofpictures, it is possible to easily achieve a special playback mode suchas a fast forward playback mode or the like.

As described above, in decoding and displaying only particular tiles,use of the slice index box 105 allows it to decode only the sliceheaders and tiles to be decoded. In decoding of a movie, a majority ofthe process is spent to decode coding tree blocks, and thus the partialdecoding using the slice index box 105 allows a great increase indecoding speed and a great reduction in power consumption compared tothe case where decoding is performed for the entire picture area or allslices. For example, in the use case illustrated in FIG. 6, decodingonly tiles specified to be decoded and having a size only one fourth thesize of the picture results in a reduction in decoding time to about onethird that of the case where the entire picture area is decoded. In acase where the present embodiment is implemented in the form of asoftware program and the software program is executed by a CPU, theelectric power consumed by the CPU in the process is reduced to aboutone third.

Another advantageous effect provided by the present embodiment is thatthe provision of the slice index box 105 (sidx) according to the presentembodiment allows it to recognize, in the playback of the media file,that the tile size is smaller than the slice size. Because it ispossible to decode each tile independently, not only in the use case inwhich only particular tiles are displayed or played back, but also in ause case in which the whole picture is decoded, a reduction in thememory used in the display or playback process is achieved. Therecognition on the relative size between tiles and slices makes itpossible to use as much memory as necessary to decode one tile insteadof using more memory necessary to decode the one whole slice. Bydecoding tiles sequentially while sharing the same memory area amongdifferent tiles, it is possible to reduce the memory size used in thedecoding.

Note that the data length of each data in the slice index box 105, theslice dividing mode, and the tile dividing mode, the character stringused as the name or the identifier of the slice index box 105, theinsertion locations in the media file, and other parameters are notlimited to the examples described above.

In the present embodiment described above, it is assumed by way ofexample that only particular tiles of a movie are extracted played back.Note that the technique according to the present embodiment is alsoapplicable to other situations. For example, the technique may beapplied to a case where one still image is coded according to the HEVCstandard and stored in a media file. As another example, in a use casein which a still image is synthesized from a plurality of pictures, onlyparticular tiles may be extracted according to the technique accordingto the present embodiment described above.

Second Embodiment

In a second embodiment described below, as in the first embodiment,coding is performed such that one slice includes a plurality of tiles.

FIG. 8 illustrates a media file format according to the secondembodiment. In FIG. 8, similar boxes and data to those illustrated inFIG. 1 are denoted by similar reference symbols, and a furtherdescription thereof is omitted. As illustrated in FIG. 8, in the sampletable box 102, the slice index box 105 illustrated in FIG. 1 is replacedby the tile index box 801.

FIG. 9A illustrates a format of the tile index box 801, and FIG. 9Billustrates an example of a content of the tile index box 801. In thepresent embodiment, it is assumed by way of example that dividing intoslices and tiles is performed in a similar manner to that illustrated inFIG. 2. As illustrated in FIG. 9A, in the tile index box 801 accordingto the present embodiment, tile indexes of the tiles at the beginningsof the respective slices (the tile indexes indicating the positions ineach picture, expressed in ordinal numbers) are stored in the order ofcoding slices. It is self-evident that the beginning of the first (as inthe coding order) slice (slice #1) includes a first (as in the codingorder) tile (tile #1), and thus no tile index is inserted for the slice#1. As illustrated in FIG. 2, a fifth tile is located at the beginningof the slice #2 and thus 4 is stored as the tile index therefor.Similarly, for following slices, tile indexes indicating the tiles atthe beginning positions are stored. When the number of tiles included ina picture is equal to M, each tile index takes one of values in a rangefrom 1 to (M−1).

In the present embodiment, a character string “tidx” (Tile Index) isused as an identifier to identify the tile index box 801. In the boxsize, the total data length of the tile index box is described as in thefirst embodiment. The number of entries is equal to the number of slicesin the picture minus 1. The data length of each entry is equal to 2bytes.

By using the tile index box 801 instead of the slice index box 105 usedin the first embodiment, a media file may be generated in a similarmanner to the first embodiment described above with reference to FIG. 4and FIG. 5. However, step S507 in FIG. 5 is performed differently fromthat according to the first embodiment in that a tile index indicating afirst-position tile is generated once for each slice and is stored inthe tile index box 801.

Also in the case where a media file is partially played back whileextracting only particular tiles, the playback process may be performedin a similar manner to that according to the first embodiment describedabove with reference to FIG. 7 by using the tile index box 801 insteadof the slice index box 105. However, step S703 in FIG. 7 is performeddifferently from that according to the first embodiment in that thetile-to-be-decoded information (set in step S702 in FIG. 7) is comparedwith the tile index included in the tile index box 801. In a case wherethe tile index of the tile to be decoded is X, an entry is searched forthat is the greatest in a range equal to or smaller than X. It ispossible to identify a slice including the tile to be decoded based onthe position, expressed using an ordinal number, of the entry.

By way of example, let it be assumed that when the tile index box 801has a content such as that illustrated in FIG. 9B, a slice including atile #10 (tile index=9) is searched for. In FIG. 9B, a third entry hasthe greatest tile index, 8, in the range equal to or smaller than 9.Thus, the process of playing back the media file is capable ofidentifying that the tile #10 is included in the slice #3. Thus, as inthe first embodiment, by analyzing the slice header of the slice #3 anddecoding only coded data of the tile #10, it is possible to quicklydecode only the tile #10.

As described above, in the present embodiment, advantageous effectssimilar to those achieved in the first embodiment are achieved using thetile index box 801. In the present embodiment, as in the firstembodiment, the data length and the content of each data in the tileindex box 801, and the manner of dividing the picture into slices andtiles are not limited to the examples described above. Furthermore, thetechnique disclosed in the present embodiment may also be applied to amedia file in which a still image is stored.

Third Embodiment

In a third embodiment described below, as in the first embodiment,coding is performed such that one slice includes a plurality of tiles.

FIG. 10 illustrates a media file format according to the thirdembodiment. In FIG. 10, similar boxes and data to those illustrated inFIG. 1 are denoted by similar reference symbols, and a furtherdescription thereof is omitted. As illustrated in FIG. 10, in the sampletable box 102, the slice index box 105 illustrated in FIG. 1 is replacedby the tile offset box 1001.

FIG. 11A illustrates a format of the tile offset box 1001 according tothe present embodiment. FIG. 11B illustrates an example of a content ofthe tile offset box 1001. As illustrated in FIG. 11A, in the tile offsetbox 1001 according to the present embodiment, the number of tile offsetbytes is stored to indicate the offset in units of bytes from thebeginning of each sample data 111 to the beginning of coded data of atile of interest. The location of a tile at the beginning of a pictureis self-evident, and thus the number of tile offset bytes for the tile#1 is not stored. In the present embodiment, a character string “tsob”(Tile in Slice Offset Byte) is used as an identifier to identify thetile offset box 1001. In the box size, the total data length of the tileoffset box 1001 is stored as in the first embodiment. The number ofentries is equal to the number of tiles in the picture minus 1. The datalength of each entry is equal to 4 bytes.

By using the tile offset box 1001 instead of the slice index box 105used in the first embodiment, a media file may be generated in a similarmanner to the first embodiment described above with reference to FIG. 4and FIG. 5. However, step S507 in FIG. 5 is performed differently fromthat according to the first embodiment in that the coded data length ofcoded data generated in the coding of slices in step S503 in FIG. 5 iscumulatively added together in the tile and in the picture, and theoffset in units of bytes is calculated from the beginning of the sampledata 111 to the beginning of coded data of each tile. A tile offset box1001 is generated by soring therein as many pieces of data indicatingthe number of tile offset bytes as the number of tiles in the pictureminus 1.

In the storing the number of tile offset bytes in the tile offset box1001, the number of tile offset bytes may vary even when the manner ofdividing a picture into tiles and slices is equal to that for a previouspicture. Therefore, step S507 in FIG. 5 is not skipped, and as many tileoffset boxes 1001 are generated as there are pictures (or as many piecesof data of number of entries are described as the number of tiles×thenumber of pictures).

Also in the case where a media file is partially played back whileextracting only particular tiles, the playback process may be performedin a similar manner to that according to the first embodiment describedabove with reference to FIG. 7 by using the tile offset box 1001 insteadof the slice index box 105. However, step S703 in FIG. 7 is performeddifferently from that according to the first embodiment in that the tileoffset box 1001 is analyzed instead of the slice index box 105.

In step S704, a tile to be decoded is determined based on thetile-to-be-decoded information set in step S702, the number of tileoffset bytes analyzed in step S703, and the data length of each NAL unitdata in the sample. After the slice header is analyzed in step S705, thecoded data of the tile is read in step S706 based on the number of tileoffset bytes.

By storing data of the number of tile offset bytes in the tile offsetbox 1001 tile offset box 1801 as described above, advantageous effectssimilar to those achieved in the first embodiment are achieved, andfurthermore it becomes possible to more quickly access coded data of thetile to be decoded, which allows a reduction in decoding time.

In the present embodiment, as in the first embodiment, the data lengthand the content of each data in the tile offset box 1001, the manner ofdividing the picture into slices and tiles are not limited to theexamples described above. Furthermore, the technique disclosed in thepresent embodiment may also be applied to a media file in which a stillimage is stored. In the present embodiment, the number of tile offsetbytes indicates the offset from the beginning of the sample data 111 tothe beginning of coded data of each tile. Alternatively, the number oftile offset bytes may indicate the offset from the beginning of codeddata of each tile to the beginning of coded data of a next tile, or thenumber of tile offset bytes may indicate the offset to the beginning ofcoded data of a slice including each tile.

Fourth Embodiment

A media file format according to a fourth embodiment described below isapplicable to a case where coding is performed such that one tileincludes a plurality of slices.

FIG. 12 illustrates a media file format according to the fourthembodiment. In FIG. 12, similar boxes and data to those illustrated inFIG. 1 are denoted by similar reference symbols, and a furtherdescription thereof is omitted. As illustrated in FIG. 12, in the sampletable box 102, the slice index box 105 illustrated in FIG. 1 is replacedby the number-of-slices-in-tile box 1201.

FIG. 13 illustrates an example of a manner of dividing a picture intoslices and tiles according to the present embodiment. FIG. 14Aillustrates a format of the number-of-slices-in-tile box 1201 accordingto the present embodiment. FIG. 14B illustrates an example of a contentof the number-of-slices-in-tile box 1201. As illustrated in FIG. 14A, inthe main body of the number-of-slices-in-tile box 1201 according to thepresent embodiment, the number of slices included in each tile isdescribed. In the present embodiment, a character string “nmsl” (TheNumber of SLice In Tile) is used as an identifier to identify thenumber-of-slices-in-tile box 1201. In the box size, as in the previousembodiments, the total data length of the whole number-of-slices-in-tilebox 1201 is described. The number of entries is equal to the number oftiles in the picture. The data length of each entry is equal to 2 bytes.

FIG. 14B illustrates an example of a content of thenumber-of-slices-in-tile box 1201 for a case in which the dividing intoslices and the dividing into tiles are performed in a manner asillustrated in FIG. 13. In FIG. 13, the picture is divided into 4 tiles,and thus the number of entries in the number-of-slices-in-tile box 1201is 4. The tile #1 and the tile #2 are each divided into 4 slices, andthus, in FIG. 14B, 4 is described as the number of slices in the tile ofeach of the tiles #1 and #2. On the other hand, the tile #3 is dividedinto 2 slices, and the tile #4 is divided into 2 slices, and thus 2 isdescribed as the number of slices in the tile of each of the tiles #3and #4.

Referring to flow charts illustrated in FIG. 15 and FIG. 16, a processof generating a media file is described below, for a case in which asillustrated in FIG. 13, coding is performed such that a picture isdivided into a plurality of tiles each including a plurality of slices.FIG. 15 is a flow chart illustrating a process of coding each slice. InFIG. 15, steps similar to those in FIG. 4 are denoted by similarreference symbols, and a further description thereof is omitted.

In step S1501, a determination is performed as to whether coding iscomplete for all coding tree blocks in the slice. In a case where thecoding is complete for all coding tree block, the processing flowproceeds to step S406 in FIG. 15, but otherwise the end-of-slice flag iscoded to 0 and the processing flow returns to step S402 in FIG. 15 tocode a following coding tree block.

FIG. 16 is a flow chart of a process of generating a media fileaccording to the present embodiment. In FIG. 16, steps similar to thosein FIG. 5 are denoted by similar reference symbols, and a furtherdescription thereof is omitted.

In step S1601, a slice is coded according to the flow chart illustratedin FIG. 15. In step S1602, a determination is performed as to whethercoding is complete for all slices in a tile. When the coding is completefor all slices, the processing flow proceeds to step S1603, butotherwise the processing flow returns to step S1601 to code a followingslice. In step S1603, based on information indicating the number ofcoded slices in the tile, the number of slices in the tile is generated.

In step S1604, a determination is performed as to whether coding iscomplete for tiles in the picture. If the coding is complete for tiles,the processing flow proceeds to step S506 in FIG. 16, but otherwise theprocessing flow returns to step S1601 to code a following tile. In stepS1605, a number-of-slices-in-tile box 1201 is generated so as toindicate the total number of slices in all tiles generated in stepS1603.

In step S1606, the sample size box 103 illustrated in FIG. 12 isgenerated based on the data length of the sample data 111 generated instep S506 in FIG. 16. A sample table box 102 is then generated bycombining therein the generated sample size box 103, thenumber-of-slices-in-tile box 1201 generated in step S1605, and the HEVCconfiguration box 104.

Referring to a flow chart illustrated in FIG. 17, a process of playingback part of a media file by extracting only particular tiles from themedia file generated based on the media file format according to thepresent embodiment. In FIG. 17, it is assumed by way of example thatonly a tile #2 illustrated in FIG. 13 is specified as a tile to bedecoded. In FIG. 17, steps similar to those in FIG. 7 are denoted bysimilar reference symbols, and a further description thereof is omitted.

In step S1701, the number-of-slices-in-tile box 1201 stored in thesample table box 102 illustrated in FIG. 12 is analyzed to acquire thenumber of slices in each tile. In step S1702, NAL unit data (coded dataof slices) included in the tile specified to be decoded is read, asdescribed below, based on the number of slices in the tile acquired instep S1701.

First, NAL unit data included in tiles prior in the coding order to thetile to be decoded is skipped. According to FIG. 14B, the number ofslices in the tile #1 (which is prior, in the coding order, to the tile#2) is 4, and thus NAL unit data of 4 slices is skipped without beingread. Skipping of NAL unit data may be easily performed based on the NALunit data length attached to each NAL unit data.

Next, NAL unit data included in the tile specified to be decoded isread. According to FIG. 14B, the number of slices in the tile #2, whichis a tile specified to be decoded, is 4, and thus 5th NAL unit data to9th NAL unit data (coded data of 4 slices) are read. Instep S1703, theslice header of each of the slices which are included in the tile to becoded and which were read in step S1702 is analyzed and codingparameters to be used in the decoding of the slice are decoded. InstepS1704, decoding is performed on the coded data of the slice read in stepS1702. The decoding in the slice may be performed in a similar manner toa general manner of decoding coding tree block, and thus a furtherdescription thereof is omitted.

In step S1705, a determination is performed as to whether the decodingis complete for all slices in the tile specified to be decoded. Forexample, in the case illustrated in FIG. 13, to decode the tile #2, itis necessary to decode the slices #5 to #8. In a case where the decodingis complete for all slices to be decoded, the processing flow proceedsto step S710 in FIG. 17, but otherwise the processing flow returns tostep S1703 in FIG. 17 to decode a following slice.

By describing the number of slices in the tile in thenumber-of-slices-in-tile box 1201 as described above, it becomespossible to quickly access coded data in the tile to be decoded even ina case where a plurality of slices are included in one tile. In decodingof a motion picture, as described above a majority of the process isspent to decode coding tree blocks. For example, in the use case inwhich only the tile #2 illustrated in FIG. 13 is displayed, decodingonly the tile #2 having a size only one fourth the size of the pictureresults in a reduction in decoding time to about one third that of thecase where the whole picture is decoded. In a case where the presentembodiment is implemented in the form of a software program and thesoftware program is executed by a CPU, the electric power consumed bythe CPU in the process is reduced to about one third.

Another advantageous effect provided by the present embodiment is thatthe provision of the number-of-slices-in-tile box 1201 (nmsl) accordingto the present embodiment allows it to recognize, in the playback of themedia file, that the tile size is greater than the slice size. Forexample, in a case where HEVC coded data is decoded in parallel by amulti-core CPU, it is possible to perform a determination, based on therelative size between tiles and slices, as to whether a plurality ofslices are decoded in parallel or a plurality of tiles are decoded inparallel.

Note that the slice index box 105 (sidx) according to the firstembodiment may be used together with the number-of-slices-in-tile box1202 (nmsl) according to the fourth embodiment. In a case where aplurality of tiles are included in one slice, it is possible to indicatethat the plurality of tiles are included in one slice by setting, to 1,the number-of-slices-in-tile box of this tile in thenumber-of-slices-in-tile box 1201. In a case where a plurality of slicesare included in one tile, it is possible to indicate that the pluralityof slices are included in one tile by setting, to 1, each slice index inthe slice index box 105.

Note that the data length of each data in the number-of-slices-in-tilebox 1201, the slice dividing mode, and the tile dividing mode, thecharacter string used as the name or the identifier of thenumber-of-slices-in-tile box 1201, the insertion locations in the mediafile, or other parameters are not limited to the examples describedabove. The embodiments described above are also applicable to a mediafile in which still images are stored. The storage location of thenumber-of-slices-in-tile box 1201 is not limited to that describedabove, but it may be stored in a VUI (video display information)parameter or a SEI (supplementary enhancement information) parameter,which is PPS or SPS parameter.

Fifth Embodiment

In a fifth embodiment described below, as in the fourth embodiment,coding is performed such that one tile includes a plurality of slices.

FIG. 18 illustrates a media file format according to the fifthembodiment. In FIG. 18, similar boxes and data to those illustrated inFIG. 1 are denoted by similar reference symbols, and a furtherdescription thereof is omitted. As illustrated in FIG. 18, in the sampletable box 102, the slice index box 105 illustrated in FIG. 1 is replacedby the tile offset box 1801.

FIG. 19A illustrates a format of the tile offset box 1801 according tothe present embodiment. FIG. 19B illustrates an example of a content ofthe tile offset box 1801. In this format, as illustrated in FIG. 19A andFIG. 19B, an offset from the beginning of sample data 111 to NAL unitdata in which a slice at the beginning of a tile is described as thenumber of tile offset bytes for each tile. In the present embodiment, acharacter string “stob” (Slice in Tile Offset Byte) is used as anidentifier to identify the tile offset box 1801. In the box size, thetotal data length of the tile offset box 1801 is stored as in the firstembodiment. The number of entries is equal to the number of tiles in thepicture. The data length of each entry is equal to 4 bytes.

By using the tile offset box 1801 instead of thenumber-of-slices-in-tile box 1201 used in the fourth embodiment, a mediafile may be generated in a similar manner to the fourth embodimentdescribed above with reference to FIG. 15 and FIG. 16. However, stepS504 in FIG. 16 is performed differently from that according to thefourth embodiment in that the coded data length of a tile is determinedby calculating the sum of the data length of NAL unit data of coded dataof each slice in the one entire tile. In step S1603 in FIG. 16, bycalculating the sum of coded data lengths of tiles in a picture, it ispossible to determine the number of tile offset bytes for the particulartile. The tile offset box 1801 is generated by storing the number oftile offset bytes for each of tiles included in a picture (except for afirst tile whose number of tile offset bytes is self-evident).

Also in the case where a media file is partially played back whileextracting only particular tiles, the playback process may be performedin a similar manner to that according to the fourth embodiment describedabove with reference to FIG. 17 by using the tile offset box 1801instead of the number-of-slices-in-tile box 1201. However, a differenceis in that the number of tile offset bytes in the tile offset box 1801obtained in step S1701 is used to step S1702 thereby making it possibleto directly access NAL unit data corresponding to a slice at thebeginning of the tile to be decoded.

In the fourth embodiment, NAL unit data included in tiles prior to thetile to be decoded is skipped without being read. In contrast, in thepresent embodiment, by using the number of tile offset bytes, it ispossible to more quickly reach the NAL unit data of the slice at thebeginning of the tile to be decoded. The number of tile offset bytes mayvary even when the manner of dividing a picture into tiles and slices isequal to that for a previous picture. Therefore, step S1701 in FIG. 17is not skipped, and as many tile offset boxes 1801 are generated asthere are pictures (or as many pieces of data of number of entries aredescribed as (the number of tiles−1)×(the number of pictures)).

By storing data of the number of tile offset bytes in the tile offsetbox 1801 as described above, advantageous effects similar to thoseachieved in the fourth embodiment are achieved, and furthermore itbecomes possible to more quickly access coded data of the tile to bedecoded, which allows a reduction in decoding time.

In the present embodiment, as in the fourth embodiment, the data lengthand the content of each data in the tile offset box 1801, and the mannerof dividing the picture into slices and tiles are not limited to theexamples described above. Furthermore, the technique disclosed in thepresent embodiment may also be applied to a media file in which a stillimage is stored.

In the present embodiment, the number of tile offset bytes indicates theoffset from the beginning of the sample data 111 in FIG. 18 to thebeginning of NAL unit data corresponding to a slice at the beginning ofeach tile. Alternatively, the number of tile offset bytes may indicatethe offset from the beginning of NAL unit data corresponding to a sliceat the beginning of each tile to NAL unit data corresponding to a sliceat the beginning of a next tile. The storage location of the tile offsetbox 1801 is not limited to that described above, but it may be stored ina VUI (video display information) parameter or a SEI (supplementaryenhancement information) parameter, which is PPS or SPS parameter.

Sixth Embodiment

In a sixth embodiment described below, coding is performed using an MCTSSEI message such that a group of pictures includes a set of MCTS tiles.As described in NPL 4, in a case where coding is performed using an MCTStile set, it is possible to decode only a particular tile set in asequence of successive pictures independently of other tiles and displaythe decoded tile set as a partial motion picture. Each picture isallowed to include a plurality of MCTS tile sets, and it is allowed touse a tile set ID (mcts_id in NPL 4), which is an identifier of a tileset, to identify a tile set to be decoded as a partial motion picture.

FIG. 21 illustrates an example in which coding is performed using MCTSfor pictures each of which is divided into slices and tiles in the samemanner as in FIG. 2. In this example, each picture includes two MCTStile sets one of which includes a rectangular tile region includingtiles #3, #4, #7, and #8 and have a tile set ID of 0, and the other oneof which includes a rectangular tile region including tiles #10, #11,#14, and #15 and have a tile set ID of 8.

FIG. 22 illustrates a media file format according to the presentembodiment. In FIG. 22, similar boxes and data to those illustrated inFIG. 1 are denoted by similar reference symbols, and a furtherdescription thereof is omitted. The media file illustrated in FIG. 22corresponds to MCTS illustrated in FIG. 21. In this media file, as manyMCTS slice index boxes 2201 as there are tile sets, that is, two MCTSslice index boxes 2201 are stored in the sample table box 102. In sampledata 111 at the beginning, a set of NAL unit data 2203 corresponding toa SEI message and a data length 2202 of this NAL unit is stored inaddition to NAL unit data 113 of coded slice data.

For example, in the HEVC coding process, by setting coding parameters inthe MCTS SEI message in NPL 4 as described below, it is possible toperform coding using the MCTS tile sets selected as illustrated in FIG.21. Of the parameters described in NPL 4, exact_sample_value_match_flagis not essential to the present embodiment, and thus a descriptionthereof is omitted.

A parameter num_sets_in_message_minus1 is set to 1, that is,num_sets_in_message_minus1=1. This parameter is stored in the SEImessage and indicates the number of tile sets coded as MCTS minus 1.When this parameter is set to 1, this means that the number of tile setsin FIG. 21 is 2.

For a first tile set located on the upper right of FIG. 21, parametersin the MCTS SEI message is set as follows.

A parameter mcts_id is set to 0, that is, mcts_id=0. This parameter is atile set ID identifying a tile set of a plurality of tile sets definedin a picture. The parameter mcts_id may take an arbitrary value selectedfrom a range fro 0 to 255. For example, when this parameter is set to 0,this means that the first tile set in FIG. 21 has a tile set ID of 0.

A parameter num_tile_rects_in_set_minus1 is set to 0, that is,num_tile_rects_in_set_minus1=0. Each tile set is allowed to include aplurality of rectangular tile groups each including a plurality of tilesin a rectangular region. The parameter num_tile_rects_in_set_minus1 isequal to the number of rectangular tile groups included in a tile setminus 1. When this parameter is set to 0, this means that the number ofrectangular tile groups forming the first tile set in FIG. 21 is 1.

A parameter top_left_tile_index[0][0] is set to 2, that is,top_left_tile_index[0][0]=2. This parameter is an index of a tilelocated at the upper left in the rectangular tile group. When thisparameter is set to 2, this means that the tile #3 in FIG. 21 is locatedat the upper left of a rectangular tile region forming the first tileset.

A parameter bottom_right_tile_index[0][0] is set to 7, that is,bottom_right_tile_index[0][0]=7. This parameterbottom_right_tile_index[0][0] is an index of a tile located at the lowerright in the rectangular tile group. When this parameter is set to 7,this means that a tile #8 in FIG. 21 is located at the lower right inthe rectangular tile group forming the first tile set.

Similarly, parameters for the second tile set, that is, the tile set atthe lower location in FIG. 21 are set as follows.

mcts_id=8

num_tile_rects_in_set_minus1=0

top_left_tile index[1][0]=9

bottom_right_tile_index[1][0]=14

In an MCTS slice index box 2201 in FIG. 22 according to the presentembodiment, information is described to indicate a slice in the picturewhose coded data includes coded data of a tile set specified as MCTS.FIG. 23A illustrates a format of the MCTS slice index box 2201, and FIG.23B illustrates an example of a content of the MCTS slice index box2201. That is, FIG. 23A illustrates an internal format of the MCTS sliceindex box 2201 according to the present embodiment. At the beginning ofthe MCTS slice index box 2201, 4-byte data is stored to indicate thetotal data length, in bytes, of the MCTS slice index box 2201. In theMCTS slice index box 2201 according to the present embodiment, the totaldata length of the box is given by 4 bytes+4 bytes+4 bytes+2 bytes+thenumber of entries×2 bytes. Following the box size, a 4-byte identifieris inserted to indicate a box type. In the present embodiment, acharacter string “mtsi” (Motion constrained Tile set Slice Index) isused as the identifier indicating the type of the MCTS slice index box2201.

Following the box type, 4-byte data is stored to indicate a tile set IDassociated with the MCTS slice index box 2201. As described above, in anSEI message stored in a HEVC coded stream, each picture is allowed toinclude a plurality of tile sets, and each tile set is assigned a tileset ID. Using the tile set ID described in the MCTS slice index box2201, it is possible to identify a tile set for which a slice index isto be specified.

Following the tile set ID, 2-byte data is inserted to indicate thenumber of entries, that is, the number of data bodies. In the MCTS sliceindex box 2201 according to the present embodiment, the number ofentries is equal to the number of slices necessary to decode thespecified tile set.

Following the number of entries, 2-byte slice indexes of respectivetiles which are necessary to decode the specified tile set are insertedas data bodies of the MCTS slice index box 2201, such that as many2-byte slice indexes are inserted as there are entries.

FIG. 23B illustrates an example of a content of an MCTS slice index box2201 corresponding to a tile set with a tile set ID of 8 in FIG. 21. InFIG. 21, each tile set includes two slices, and thus the number ofentries is 2, and the data size is given by 4+4+4+2+2×2=18 bytes.

Following the number of entries, slice indexes of slices necessary todecode the tile set are inserted. As illustrated in FIG. 21, to decodethe tile set with the tile set ID of 8, two slices, that is, the slice#3 and the slice #4 are necessary, and thus 2 and 3 are stored as sliceindexes.

In the present embodiment, the MCTS slice index box 2201 is basicallystored in the sample table box 102. However, the box in which the MCTSslice index box 2201 is stored is not limited to the sample table box102. That is, the MCTS slice index box 2201 may be stored in any box inthe movie box 101.

A media file may be generated in a similar manner to that according tothe first embodiment described above with reference to FIG. 4 and FIG. 5except that the MCTS slice index box 2201 is used instead of the sliceindex box 105 according to the first embodiment.

However, in step S402 illustrated in FIG. 4, coding of a coding treebelonging to MCTS is performed without using a motion vector that refersto a tile outside MCTS on a reference frame.

In generating a slice header of each slice in step S408, when a sliceincludes an MCTS tile, a slice index is generated. In step S501 in FIG.5, it is necessary to set which tile is in MCTS in a video sequence.Furthermore, in the setting associated with the division into tiles instep S502, the setting is performed so as to satisfy conditionsassociated with MCTS described in NPL 4. That is, each picture isdivided into tiles in the same manner for all pictures in the sequence,and an MCTS SEI message is generated and stored as NAL unit data insample data at the first picture.

When the process in step S507 is performed for the first picture, anMCTS slice index box 2201 is generated not based on the slice index box105 but based on the slice index generated in step S408. The MCTS sliceindex box 2201 generated in step S510 is stored thereby generating asample table box 102.

In the example described above, each picture has two MCTS tile sets, andeach MCTS tile set has one rectangular tile group. However, theembodiment is not limited to this example. That is, the number of MCTStile sets and the number of rectangular tile groups in each tile set maybe set to arbitrary values as long as no conflict with the number oftiles in the picture occurs.

Furthermore, the number of MCTS slice index boxes stored does not needto be equal to the number of tile sets as in the above-describedexample. When there is Y MCTS tile sets in a picture, it is allowed tostore Y or less MCTS slice index box 2201 in the sample table box 102.However, tile set IDs in each MCTS slice index box 2201 have valuesdifferent from each other.

In the above description, it is assumed by way of example, but notlimitation, that coding is performed such that each picture is dividedinto slices in the same manner. In a case where the manner of dividingpictures into slices are not the same for all pictures, a new MCTS sliceindex box 2201 is generated each time a change occurs in the divisioninto slices, and the generated MCTS slice index box 2201 is stored inthe sample table box 102.

Referring to a flow chart illustrated in FIG. 24, a description is givenbelow as to a procedure of extracting particular MCTS tile sets from amedia file generated based on the media file format according to thepresent embodiment and decoding the extracted MCTS tile sets therebyplaying back a part of the media file. In FIG. 24, it is assumed that atile set with a tile set ID=8 in FIG. 21 is set to be decoded. In FIG.24, steps similar to those in FIG. 7 are denoted by similar referencesymbols, and a further description thereof is omitted.

In step S2401, an MCTS SEI message included in SEI data 2203 in a firstsample such as that illustrated in FIG. 22 is analyzed to detect a tileset ID of each tile set specified as MCTS, and a rectangular tile groupto be decoded is calculated.

In step S2402, a tile set ID of a tile set to be decoded is selectedfrom tile sets included in the MCTS SEI message analyzed in step S2401.

In step S2403, an MCTS slice index box 2201 having the same tile set IDas the tile set ID specified in step S2402 is selected, and the selectedMCTS slice index box 2201 is analyzed to identify coded slice data to bedecoded. Based on information associated with a tile group to be decodedobtained from the identified coded slice data and the MCTS SEI message,the process in step S704 and following steps is performed in a similarmanner to that according to the first embodiment thereby decoding tilesspecified to be decoded.

As described above, also in the case where the MCTS slice index box 2201is used, advantageous effects similar to those provided in the firstembodiment are achieved. In particular, it is possible to quickly decodeonly tile sets specified to be decoded from a sequence based onconstrained conditions associated with MCTS without referring to anytile other than the specified tile sets, which allows a further increasein speed of the decoding process.

Note that also in the present embodiment, the data length and thecontent of each piece of data in the MCTS slice index box 2201, theslice dividing mode, and the tile dividing mode, the character stringused as the name or the identifier of the MCTS slice index box 2201, theinsertion locations in the media file, and other parameters are notlimited to the examples described above. Furthermore, the techniquedisclosed in the present embodiment may also be applied to a media filein which a still image is stored.

Seventh Embodiment

In a seventh embodiment described below, a picture group is coded usingan MCTS SEI message as in the sixth embodiment and the coding isperformed such that one tile includes a plurality of slices. The mediafile format used in the seventh embodiment may be similar to thataccording to the sixth embodiment described above with reference to FIG.22.

In the present embodiment, a rectangular tile group including two tiles#1 and #3 illustrated in FIG. 13 is coded as an MCTS tile set with atile set ID of 0. FIG. 25 illustrates an MCTS slice index box indicatingcoded slice data necessary in decoding the MCTS tile set.

As illustrated in FIG. 13, the tile #1 includes four pieces of codedslice data, and the tile #3 includes two pieces of coded slice data, andthus the tile set to be decoded includes six pieces of coded slice data.Thus, 6 is described as the number of entries in the MCTS slice indexbox in FIG. 25, and slice indexes 0, 1, 2, 3, 8, and 9 are described asdata body to indicate tiles #1, #2, #3, #4, #9, and #10. Furthermore, adata size stored at the beginning of the MCTS slice index box 2201 is4+4+4+2+2×6=26 bytes.

Also in the case where a particular MCTS tile set is extracted anddecoded thereby playing back a particular part of a media file,performing a process in a similar manner as in the sixth embodimentdescribed above makes it possible to quickly decode only the specifiedtile set. Thus, also in the case where each picture in a video sequenceis divided into tiles and slices such that one tile include a pluralityof slices as in the present embodiment, advantageous effects similar tothose provided in the sixth embodiment are achieved.

Note that also in the present embodiment, as in the sixth embodiment,the data length and the content of each piece of data in the MCTS sliceindex box 2201, the mode of dividing each picture into slices and tiles,the character string used as the name or the identifier of the MCTSslice index box 2201, the insertion locations in the media file, andother parameters are not limited to the examples described above.Furthermore, the technique disclosed in the present embodiment may alsobe applied to a media file in which a still image is stored.

Eighth Embodiment

In an eighth embodiment described below, a tile set specified as MCTSused in the sixth embodiment and the seventh embodiment is explicitlyspecified as a region of interest (ROI) with priority.

FIG. 26 illustrates a media file format according to the eighthembodiment. In FIG. 26, similar boxes and data to those illustrated inFIG. 22 are denoted by similar reference symbols, and a furtherdescription thereof is omitted.

In the present embodiment, as illustrated in FIG. 26, following the MCTSslice index box 2201, a ROI tile set box 2601 is stored in the sampletable box 102. Note that in the example of the media file illustrated inFIG. 26, it is assumed, as in the sixth embodiment, that coding isperformed such that each picture includes two MCTS tile sets asillustrated in FIG. 21.

In the present embodiment, as illustrated in FIG. 26, the media fileincludes a ROI tile set box 2601 indicating MCTS tile sets specified asa ROI with priority. FIG. 27A illustrates a format of the ROI tile setbox 2601, and FIG. 27B illustrates an example of a content of the ROItile set box 2601.

FIG. 27A illustrates an example of an internal format of the ROI tileset box 2601 according to the present embodiment. At the beginning ofthe ROI tile set box 2601, 4-byte box size data is stored to indicatethe total data length, in bytes, of the ROI tile set box 2601. In thepresent example, the total data length of the ROI tile set box 2601 isgiven by 4 bytes+4 bytes+2 bytes+the number of entries×5 bytes.

Following the box size, a 4-byte identifier is inserted to indicate abox type. In the present embodiment, a character string “rits”(Region ofInterest Tile Set) is used as the identifier to identify the type of theROI tile set box 2601.

Following the box type, 2-byte data is inserted to indicate the numberof entries, that is, the number of data bodies. In the ROI tile set box2601 according to the present embodiment, the number of entries is equalto the number of tile sets included in the specified ROI. Following thenumber of entries, 4-byte data representing a tile set ID of a tile setspecified as being included in a ROI and 1-byte data representing ROIpriority of this tile set (and thus a total of 5 bytes) are inserted asdata body of the ROI tile set box 2601. Note that as many pieces ofthese data are inserted as there are entries. As for the ROI priority, avalue is selected from a range from 0 to 255 to indicate the priority ofdisplaying the tile set as the ROI. Note that the higher the value, thehigher the priority.

FIG. 27B illustrates an example of a content of the ROI tile set box2501 for a case where the tile set with the tile set ID=0 on the upperright of FIG. 21 is specified as a low-priority ROI, and the tile setwith the tile set ID=8 on the bottom of FIG. 21 is specified as ahigh-priority ROI. There are two tile sets specified as ROIs, and thusthe number of entries is 2, and the data size is given by 4+4+2+2×5=20bytes.

Following the number of entries, a value of 0 is described to indicatethat the tile set ID is 0 and furthermore a value of 0 is described toindicate that the ROI priority of this tile set is 0, that is, this tileset is specified as a low-priority region of interest. Subsequently, avalue 8 is described to indicate that the tile set ID is 8 andfurthermore a value of 255 is described to indicate that the ROIpriority of this tile set is 255, that is, this tile set is specified asa high-priority region of interest.

The ROI tile set box 2601 is basically stored in the sample table box102. Note that the ROI tile set box 2601 may be stored in another box.That is, the ROI tile set box 2601 may be stored in any box in the moviebox 101.

A media file may be generated in a similar manner to the sixthembodiment described above with reference to FIG. 4 and FIG. 5. However,in step S501 in FIG. 5, setting is performed as to which tile isspecified as being included in MCTS in a video sequence and which tileset in the MCTS is specified as being included in a ROI, and furthermoresetting is performed to specify the priority for each ROI. The settingas to the specifying of the ROI and the priority thereof may beperformed based on information generally obtainable when a picture istaken using a camera as to a face or a figure of a person, an object, orthe like recognized from the picture, or based on person identificationinformation of a particular person.

Furthermore, in step S507 in FIG. 5, the ROI tile set box 2601 isgenerated in addition to the MCTS slice index box 2201. In the processof generating the sample table box in step S510, the ROI tile set box2601 is stored together with the MCTS slice index box 2201.

Also in the case where a particular MCTS tile set is extracted anddecoded thereby playing back a particular part of a media file,performing a process in a similar manner as in the sixth embodimentdescribed above with reference to FIG. 24 makes it possible to quicklydecode only the specified tile set as a partial motion picture.

However, in step S2402, the priority of the ROI to be played back isspecified by a user. Based on the specified ROI priority, the ROI tileset box 2601 is referred to, and the tile set ID of the MCTS tile set tobe played back is calculated. An MCTS slice index box 2201 with thecalculated tile set ID is searched for, and, based on the retrieved MCTSslice index box 2201, it is possible to identify coded slice datanecessary to decode the tile set to be decoded.

In the present embodiment, the capability of specifying a particularMCTS tile set as a ROI with priority provides an advantageous effectthat a tile set to be decoded may be determined depending on the ROIpriority specified by a user, in addition to advantageous effectssimilar to those provided by the sixth embodiment.

Note that also in the present embodiment, the data length and thecontent of each piece of data in the ROI tile set box 2601, the mode ofdividing each picture into slices and tiles, the character string usedas the name or the identifier of the ROI tile set box 2601, theinsertion locations in the media file, and other parameters are notlimited to the examples described above. Furthermore, the techniquedisclosed in the present embodiment may also be applied to a media filein which a still image is stored.

Ninth Embodiment

In a ninth embodiment described below, specifying a region of interest(ROI) and priority thereof used in the eighth embodiment is applied to acase where each picture includes only normal tiles which are not ofMCTS.

FIG. 28 illustrates a media file format according to the presentembodiment. In FIG. 24, similar boxes and data to those illustrated inFIG. 22 are denoted by similar reference symbols, and a furtherdescription thereof is omitted.

In the present embodiment, as illustrated in FIG. 28, a ROI tile indexbox 2801 is stored together with the slice index box 105 in the sampletable box 102. Note that FIG. 28 illustrates a particular example inwhich there is only one region specified as a ROI. In a case where thereare N regions specified as ROIs, N ROI tile index boxes 2801 are storedin the sample table box 102.

FIG. 29A illustrates an internal format of the ROI tile index box 2801according to the present embodiment. At the beginning of the ROI tileindex box 2801, 4-byte box size data is stored to indicate the totaldata length, in bytes, of the ROI tile index box 2801. In the ROI tileindex box 2801 according to the present embodiment, the total datalength of the box is given by 4 bytes+4 bytes+4 bytes+1 bytes+2bytes+the number of entries×2 bytes.

Following the box size, a 4-byte identifier is inserted to indicate abox type. In the present embodiment, a character string “riti” (Regionof Interest Tile Index) is used as the identifier indicating the type ofthe ROI tile index box 2801.

Following the box type, a 4-byte ROI ID is inserted to identify aspecified region of interest. As with the tile set ID according to thesixth embodiment, the ROI ID may have a value arbitrarily selected froma range from 0 to 255. However, in a case where a plurality of ROIs aredefined in a picture, and a plurality of ROI tile index boxes 2801 arestored in the sample table box 102, the ROI IDs in the respective ROItile index boxes 2801 are set to have different values.

Following the ROI ID, 1-byte ROI priority is inserted to indicate thepriority of the specified region. As in the eighth embodiment, the valueof the ROI priority is selected from a range from 0 to 255 such that thehigher the value, the higher the priority.

Following the ROI priority, 2-byte data is inserted to indicate thenumber of entries, that is, the number of data bodies. In the ROI tileindex box 2801 according to the present embodiment, the number ofentries is equal to the number of tiles included in the ROI. Followingthe number of entries, as many 2-byte tile indexes as there are entriesare inserted as data bodies of the ROI tile index boxes 2801 to indicaterespective tiles of the ROI. The tile index is defined in the samemanner as in the second embodiment, and thus a further descriptionthereof is omitted.

FIG. 29B illustrates an example of a content of the ROI tile set box2801 for a case where when a picture is divided into slices and tiles inthe manner described in FIG. 2, four tiles #6, #7, #10, and #11 arespecified as being included in a high-priority ROI with a ROI ID of 1.

There are 4 tiles in the ROI, and thus the number of entries is 4 andthe data size is given by 4+4+4+1+2×4=23 bytes. Following the box type,a value of 1 is described to indicate that ROI ID=1, and furthermore avalue of 255 is described to indicate that the priority of this ROI isas high as 255.

Following the ROI priority, a value of 4 is inserted as the number ofentries, and furthermore, tile indexes 5, 6, 9, and 10 are inserted asdata bodies of the ROI tile index box 2801 to respectively indicatetiles #6, #7, #10, and #11 included in the ROI.

The ROI tile index box 2801 is basically stored in the sample table box102. However, the ROI tile index box 2801 may be stored in another box.That is, the ROI tile index box 2801 may be stored in any box in themovie box 101.

A media file may be generated in a similar manner as in the firstembodiment described above with reference to FIG. 4 and FIG. 5. However,in step S502 in FIG. 5, setting is performed as to which tile set in thepicture is specified as being included in a ROI, and furthermore settingis performed to specify the priority for each ROI. The setting as to thespecifying of the ROI and the priority thereof may be performed based oninformation generally obtainable when a picture is taken using a cameraas to a face or a figure of a person, an object, or the like recognizedfrom the picture, or based on person identification information of aparticular person.

Furthermore, instep S507 in FIG. 5, the ROI tile index box 2801 isgenerated in addition to the slice index box 105. In the process ofgenerating the sample table box in step S510, the ROI tile index box2801 is stored together with the slice index box 105.

Also in the case where a media file is partially played back whileextracting only particular ROI tiles, performing a process in a similarmanner as in the first embodiment described above with reference to FIG.7 makes it possible to quickly decode only the ROI. In step S702, thepriority of the ROI to be played back is specified, for example, by auser. Based on the specified ROI priority, in step S702, the ROI tileindex box 2801 with the specified priority is referred to, and the tileindex of the ROI to be played back is calculated.

In step S703, coded slice data necessary to decode the tiles included inthe ROI calculated in step S702 is identified based on the slice indexbox 105. In step S704 and following steps, the identified coded slicedata is decoded thereby decoding the ROI.

In the present embodiment, also in the case where MCTS is not used, thecapability of specifying tiles forming a ROI by IDs and tile indexeswith priority makes it possible to achieve advantageous effects similarto those provided in the eighth embodiment. However, because MCTS is notused, there is a possibility that, in decoding, it becomes necessary torefer to a tile other than ROI tiles. This may cause the decoding speedto be lower than that achieved by the eighth embodiment using the MCTS.

Note that also in the present embodiment, the data length and thecontent of each data in the ROI tile index box 2801, the mode ofdividing each picture into slices and tiles, the character string usedas the name or the identifier of the ROI tile index box 2801, theinsertion locations in the media file, and other parameters are notlimited to the examples described above. Furthermore, the techniquedisclosed in the present embodiment may also be applied to a media filein which a still image is stored. The technique disclosed in the presentembodiment may also be applied to a case where one or both of the ROI IDand the ROI priority are not used.

The method of specifying a tile group as a region of interest is notlimited to directly specifying a tile group by tile indexes as with themethod described above. For example, a rectangular region may bespecified as a region of interest by specifying an index of a tile onthe upper left of the rectangular region and an index of a tile on thelower right of the rectangular region.

In a case where either a ROI ID or ROI priority does not exist, a usermay determine a ROI by using available one of the ROI ID or the ROIpriority in playing back a media file.

In the present embodiment, instead of the slice index box 105, the tileindex box 801 according to the second embodiment may be used as data inthe media file. In this case, it is possible to identify a slicenecessary to decode a ROI, by comparing the tile index box 801 with thetile index of the ROI to be decoded.

Furthermore, the present embodiment may be applied to a case where thereis no slice index box 105 as data in the media file. However, in thiscase, a slice header is analyzed for all pieces of coded slice data in apicture, and, based on the location-in-picture of each slice and thetile division information, a determination is performed as to whetherthe slice is necessary in decoding a ROI.

The analysis of the slice headers of all pieces of coded slice dataresults in an increase in decoding time compared with the case where theslice index box 105 exists. However, even in this case, the decodingtime is greatly reduced compared with the case where the whole picturearea is first decoded and then a ROI part is extracted.

Furthermore, the present embodiment may also be applied to a case whereeach picture is not divided into a plurality of slices, but coding isperformed such that the picture include a single slice. In this case, byreferring to the ROI tile index box 2801 and the entry point offset ofeach tile included in the slice header described above in the firstembodiment, it is possible to quickly access coded data of tilesnecessary to decode the ROI and thus it is possible to quickly decodethe ROI.

Tenth Embodiment

In a tenth embodiment described below, a determination is performed asto whether the MCTS or the ROI tile described in the sixth to ninthembodiments is valid at each point of a time sequence.

FIG. 30 illustrates an example in which a motion of a subject or amotion of a motion picture tacking apparatus causes an object ofinterest such as a figure of a person or the like to temporarily go outof a region of interest of a picture. In FIG. 30, it is assumed by wayof example that coding is performed such that two MCTS tile sets withtile set IDs of 0 and 8, respectively, are specified as region ofinterests.

In the tile set with the tile set ID of 0, as illustrated in FIG. 30,the object of interest is not included in this tile set over a periodfrom a sample #0 at the top of a sequence to a sample #21. On the otherhand, in the tile set with the tile set ID of 8, the object of interestis included in this tile set in a period from the sample #0 at the topof the sequence to a sample #14 and in a period from a sample #30 to asample #38, but the object of interest is not included in this tile setin the other periods.

FIG. 31 illustrates a media file format according to the presentembodiment. In FIG. 31, similar boxes and data to those illustrated inFIG. 22 are denoted by similar reference symbols, and a furtherdescription thereof is omitted. In the present embodiment, asillustrated in FIG. 31, the ROI valid sample box 3101 is stored togetherwith the MCTS slice index box 2201 in the sample table box 102.

In the example illustrated in FIG. 31, it is assumed that there are twotile sets for which valid samples are to be specified. In a case wherethere are M tile sets or M ROI tiles for which valid samples are to bespecified, M ROI valid sample boxes 3101 are stored in the sample tablebox 102.

In the present embodiment, regarding the MCTS tile set or the ROI tile,each ROI valid sample box 3101 illustrated in FIG. 31 includesinformation indicating which sample in a time sequence is a valid samplein which an object of interest exists in the tile set. FIG. 32Aillustrates a format of the ROI valid sample box 3101, and FIGS. 32B and32C illustrates examples of contents of ROI valid sample box 3101.

FIG. 32A illustrates an internal format of the ROI valid sample box 3101according to the present embodiment. At the beginning of the ROI validsample box 3101, 4-byte box size data is stored to indicate the totaldata length, in bytes, of the ROI valid sample box 3101. In the ROIvalid sample box 3101 according to the present embodiment, the totaldata length of the box is given by 4 bytes+4 bytes+4 bytes+2 bytes+thenumber of entries×8 bytes.

Following the box size, a 4-byte identifier is inserted to indicate abox type. In the present embodiment, a character string “rivs” (Regionof Interest Valid Samples) is used as the identifier indicating the typeof the ROI valid sample box 3101.

Following the box type, 4-byte data is stored to represent a tile set IDidentifying a tile set for which valid samples are to be specified. Inthe ROI valid sample box 3101, information is described to indicatewhether an object of interest is included in a tile set with the tileset ID described herein. Note that the information in the ROI validsample box 3101 is given only for the tile set with this tile set ID.

Following the tile set ID, 2-byte data is inserted to indicate thenumber of entries, that is, the number of data bodies. In the ROI validsample box 3101 according to the present embodiment, the number ofentries is equal to the number of times that a period includingsuccessive samples that are all valid occurs in the tile set ofinterest.

Following the number of entries, 4-byte data indicating a start sampleof valid samples and 4-byte data indicating the number of successivevalid samples in a period, that is, a total of 8-byte data is insertedas data bodies of the ROI valid sample box 3101. Note that as manypieces of such data are inserted as there are entries.

FIG. 32B illustrates an example of a content of a ROI valid sample box3101 associated with valid samples corresponding to the tile set withthe tile set ID of 0 in FIG. 30. FIG. 32C illustrates an example of acontent of a ROI valid sample box 3101 associated with valid samplescorresponding to the tile set with the tile set ID of 8 in FIG. 30.

As illustrated in FIG. 32B, in the tile set with the tile set ID of 0illustrated in FIG. 30, there is one period including successive samplesthat are all valid. Thus, the data size is 4+4+4+2+1×8=22 bytes, thetile set ID is 0, and the number of entries is 1. Following the numberof entries, a value of 22 indicating a sample #22 as the start sample ofthe valid period and a value of 16 indicating the number of successivevalid samples are inserted as data bodies of the ROI valid sample box3101.

Similarly, as illustrated in FIG. 32C, in the tile set with the tile setID of 8, there are two periods during each of which all successivesamples are valid. Thus, the data size is inserted as 4+4+4+2+2×8=30bytes. A value of 0 is then inserted to indicate a sample #0 as thestart sample of the first valid period. Subsequently, a value of 14 isinserted to indicate the number of successive valid samples. A value of30 is then inserted to indicate a sample #30 as the start sample of thesecond valid period. Subsequently, a value of 8 is inserted to indicatethe number of successive valid samples.

A media file may be generated in a similar manner to the sixthembodiment described above with reference to FIG. 4 and FIG. 5. However,in step S507 in FIG. 5, a determination as to whether each tile setincludes validation information is performed based on a recognitionresult, an authentication result, or the like, and the MCTS slice indexbox 2201 is generated depending on a result of the determination. Instep S510, the ROI valid sample box 3101 is generated based on thevalidation information and stored together with the MCTS slice index box2201 in the sample table box 102.

Thus, also in the case where a particular MCTS tile set is extracted anddecoded thereby playing back a particular part of a media file,performing a process in a similar manner as in the sixth embodimentdescribed above with reference to FIG. 24 makes it possible to quicklydecode only the specified tile set. However, in step S2402, the ROIvalid sample box 3101 with the tile set ID corresponding to a tile setto be decoded is analyzed to determine whether each sample correspondingto a picture, in the tile set to be decoded, is valid or not. In a casewhere a sample under analysis is not valid, the decoding and thedisplaying of the invalid picture is skipped until a picture including avalid sample is reached. When the valid sample is reached, the decodingis started. Thus, for a tile set defining a region of interest, it ispossible to decode only pictures including an object of interest andthus it is possible to perform the decoding process in an efficientmanner.

For example, in a case where a tile set with a tile set ID of 8 in FIG.30 is specified by a user to be decoded, if the ROI valid sample box3101 is not used, it is necessary to decode the specified tile set overall 39 pictures. In contrast, when the ROI valid sample box 3101 isavailable, the ROI valid sample information included in the ROI validsample box 3101 is referred to, and it is allowed to decode the tile setfor only pictures in which an object of interest is included in the tileset. In this case, the tile set is decoded for only 15+9=24 pictures.

Note that also in the present embodiment, the data length and thecontent of each data in the ROI valid sample box 3101, the mode ofdividing each picture into slices and tiles, the character string usedas the name or the identifier of the ROI valid sample box 3101, theinsertion locations in the media file, and other parameters are notlimited to the examples described above.

In the present embodiment, the ROI valid sample box 3101 may specifywhether an object of interest is included in a region of interest for anMCTS tile set specified as a ROI according to the eighth embodiment, orfor a ROI tile using no MCTS according to the ninth embodiment. Tospecify a valid sample period of a ROI tile according to the ninthembodiment, a ROI ID described above with reference to FIGS. 29A and 29Bmay be used instead of a tile set ID in FIGS. 32A to 32C to indicatewhich sample in which ROI is valid.

In the present embodiment, a period in which a tile set is valid isspecified in units of samples corresponding to pictures. However, thepresent embodiment is not limited to this scheme. For example, it may beallowed to specify a period in which a tile set is valid, by specifyinga display time of a picture (start time of a valid period) and a validduration. Alternatively, it may be allowed to specify a period in whicha tile set is valid by specifying a start sample and an end sample.Still alternatively, it may be allowed to specify a period in which atile set is valid by specifying a start display time and an end displaytime.

In the present embodiment, it is assumed that a media file includes onevideo sequence. However, the present embodiment is not limited to this.That is, a media file may include a plurality of video sequences. It maybe allowed to provide information indicating whether or not each regionof interest includes an object of interest in units of video sequences.In this case, a sequence ID serving as an identifier of a video sequencemay be stored as a valid sequence ID instead of the set of the validstart sample and the number of successive valid samples in the ROI validsample box 3101 described above with reference to FIGS. 32A to 32C.

For example, in a case where a media file includes four video sequenceswith sequence IDs 0 to 3, when an object of interest is included only inthe video sequences with the sequence IDs of 1 and 3, then values of 1and 3 indicating valid sequence IDs are stored as data bodies in the ROIvalid sample box 3101.

In the case where a valid sequence ID is used instead of valid samplesto indicate whether each region of interest includes an object ofinterest, it is possible to achieve advantageous effects similar tothose achieved by use of the valid samples.

Other Embodiments

FIG. 20 is a block diagram illustrating an example of a hardwareconfiguration of a computer that executes a program to perform theprocesses according to any embodiment described above.

A CPU 2001 controls a whole computer using a computer program andassociated data stored in a RAM 2002 or ROM 2003, and furthermore, theCPU 2001 executes the process according to one of the embodimentsdescribed above.

The RAM 2002 includes a memory area in which a computer program andassociated data loaded from an external storage device 2006, data inputfrom the outside via an interface (I/F) 2007, and the like aretemporarily stored. The RAM 2002 also includes a work area used by theCPU 2001 to execute various processes. The RAM 2002 may be allocated asa frame memory or the like, and the RAM 2002 may provide various memoryareas as required.

In the ROM 2003, setting data of the computer, a boot program, and thelike are stored. An operation unit 2004 includes a keyboard, a mouse,and the like, and is operated by a user of the computer to input variouscommands into the CPU 2001. An output unit 2005 outputs a result of theprocess performed by the CPU 2001. The output unit 2005 may be, forexample, a display such as a liquid crystal display, and the result ofthe process may be displayed thereon.

The external storage device 2006 may be a high-storage informationstorage device typified by a hard disk drive. In the external storagedevice 2006, an operating system (OS) and computer programs are storedto make it possible for the CPU 2001 to execute the process according toone of the embodiments described above. The external storage device 2006may also be used to store images to be processed.

The computer programs and data stored in the external storage device2006 are loaded, under the control of the CPU 2001, into the RAM 2002 asrequired, and executed by the CPU 2001. The I/F 2007 may be connected toa network such as a LAN, the Internet, or the like and anotherapparatuses such as a projection apparatus, a display apparatus, or thelike thereby making it possible for the computer to input or outputvarious kinds of information via the I/F 2007. The units described aboveare connected to each other via a bus 2008.

Other Embodiments

Aspects of the present invention can also be realized by a computer of asystem or apparatus (or devices such as a CPU or MPU) that reads out andexecutes a program recorded on a memory device to perform the functionsof the above-described embodiment(s), and by a method, the steps ofwhich are performed by a computer of a system or apparatus by, forexample, reading out and executing a program recorded on a memory deviceto perform the functions of the above-described embodiment(s). For thispurpose, the program is provided to the computer for example via anetwork or from a recording medium of various types serving as thememory device (e.g., computer-readable medium).

While the present invention has been described with reference toexemplary embodiments, it is to be understood that the invention is notlimited to the disclosed exemplary embodiments. The scope of thefollowing claims is to be accorded the broadest interpretation so as toencompass all such modifications and equivalent structures andfunctions.

1. A method for generating a media file, the method comprising:obtaining image data which is coded according to a plurality of tileregions; and generating a media file including a first portion and asecond portion, wherein the second portion is placed after the firstportion in the media file, wherein the second portion includes theobtained image data which is coded according to the plurality of tileregions, and wherein the first portion includes offset informationrelating to a data position for the plurality of tile regions in thesecond portion.
 2. The method according to claim 1, wherein the firstportion of the media file further includes sample size informationindicating a data size of each of a plurality of pictures correspondingto the coded image data.
 3. The method according to claim 1, wherein themedia file includes a third portion for indicating a file type of themedia file, wherein the third portion is placed in front of the firstportion.
 4. The method according to claim 1 wherein the image data isobtained by encoding processing based on HEVC (High Efficiency VideoCoding) standard.
 5. The method according to claim 1, wherein the firstportion further includes tile size information indicating a size of eachof the plurality of tile regions.
 6. The method according to claim 1,wherein a size of the tile regions in a first picture and a size of thetile regions in a second picture are different with each other.
 7. Themethod according to claim 1, wherein the obtained image data is dividedinto one or more slices, and wherein at least two tile regions areincluded in one slice.
 8. The method according to claim 1, wherein thefirst portion of the media file further includes tile number informationindicating a number of tile regions in a picture.
 9. An apparatus forgenerating a media file, the apparatus comprising: one or more hardwareprocessors; and a memory for storing instructions to be executed by theone or more hardware processors, wherein when the instructions stored inthe memory are executed by the one or more hardware processors, theapparatus performs operations of: obtaining image data which is codedaccording to a plurality of tile regions; and generating a media fileincluding a first portion and a second portion, wherein the secondportion is placed after the first portion in the media file, wherein thesecond portion includes the obtained image data which is coded accordingto the plurality of tile regions, and wherein the first portion includesoffset information relating to a data position for the plurality of tileregions in the second portion.
 10. The apparatus according to claim 9,wherein the first portion of the media file further includes sample sizeinformation indicating a data size of each of a plurality of picturescorresponding to the coded image data.
 11. The apparatus according toclaim 9, wherein the media file includes a third portion for indicatinga file type of the media file, wherein the third portion is placed infront of the first portion.
 12. The apparatus according to claim 9wherein the image data is obtained by encoding processing based on HEVC(High Efficiency Video Coding) standard.
 13. A non-transitorycomputer-readable storage medium storing a program for causing acomputer to execute a method for generating a media file, the methodcomprising: obtaining image data which is coded according to a pluralityof tile regions; and generating a media file including a first portionand a second portion, wherein the second portion is placed after thefirst portion in the media file, wherein the second portion includes theobtained image data which is coded according to the plurality of tileregions, and wherein the first portion includes offset informationrelating to a data position for the plurality of tile regions in thesecond portion.
 14. The medium according to claim 13, wherein the firstportion of the media file further includes sample size informationindicating a data size of each of a plurality of pictures correspondingto the coded image data.
 15. The medium according to claim 13, whereinthe media file includes a third portion for indicating a file type ofthe media file, wherein the third portion is placed in front of thefirst portion.
 16. The medium according to claim 13 wherein the imagedata is obtained by encoding processing based on HEVC (High EfficiencyVideo Coding) standard.